Security systems and methods for continuous authorized access to restricted access locations

ABSTRACT

Systems and methods for authorized access to restricted access locations. A first and/or second device includes a secure storage storing security credentials associated with a user for authorized access to restricted access locations. The second device is associated with a unique identifier. A processor of the first device is configured to: detect a presence of the second device within a predetermined proximity range of the first device; establish a communication channel between the first and second devices; receive the unique device identifier from the second device via the communication channel; determine whether the received unique device identifier matches a predetermined identifier in the secure storage, to validate the second device; determine whether the first and second devices maintain a predefined connection state; and permit access to the security credentials stored on the secure storage when the second device is validated and the predefined connection state is maintained.

TECHNICAL FIELD

The present disclosure relates generally to digital security systemsand, in particular, systems and methods for authorized access to one ormore restricted access locations, identity management and restrictedaccess monitoring using first and second electronic devices.

BACKGROUND

More electronic devices are connecting online to a variety of services,websites, applications, etc. Current secure access solutions (e.g., useridentity (ID), password) based on, for example, keyboard input and/oruniversal serial bus (USB) sticks may not be practical. For example, notall devices need or have a keyboard or a USB port. Nevertheless, alltypes of devices may need protection. Consumers and employees maydislike passwords and may tend to forget them. Furthermore, these samepasswords, no matter how complex, may be repeatedly exploited byattackers to gain access to restricted information and devices. TheIndustrial Internet/Industry 4.0 (i.e., the integration of physicalmachinery with networked sensors and software) may also need protection.A new solution is needed that solves for secure access across alldevices (industrial and consumer).

SUMMARY

Aspects of the present disclosure relate to security systems and methodsfor authorized access to one or more restricted access locations. Asecurity system includes a first electronic device, a second electronicdevice and a secure storage on at least one of the first electronicdevice and the second electronic device. The first electronic deviceincludes a non-transitory memory storing computer-readable instructionsand a processor. The second electronic device is associated with aunique device identifier. Each of the first electronic device and thesecond electronic device includes a wireless communication interface forwireless communication therebetween. The secure storage is configured tostore one or more security credentials associated with a user forauthorized access to one or more restricted access locations. Executionof the computer-readable instructions by the processor of the firstelectronic device causes the processor to: detect a presence of thesecond electronic device within a predetermined proximity range of thefirst electronic device, based on an indication received from the secondelectronic device via the respective wireless communication interface;establish a communication channel between the first electronic deviceand the second electronic device via each wireless communicationinterface, responsive to the detected presence of the second electronicdevice; receive the unique device identifier from the second electronicdevice via the communication channel; determine whether the receivedunique device identifier matches a predetermined identifier stored inthe secure storage, to validate the second electronic device; determinewhether the first electronic device and the second electronic devicemaintain a predefined connection state; and permit access to the one ormore security credentials stored on the secure storage when the secondelectronic device is validated and the predefined connection state ismaintained.

Aspects of the present disclosure also relate to security systems andmethods for authorized access to one or more restricted accesslocations. A security system includes a first electronic device, asecond electronic device and a secure storage on at least one of thefirst electronic device and the second electronic device. The firstelectronic device includes a non-transitory memory storingcomputer-readable instructions, a processor and a user interface. Thesecond electronic device is associated with a unique device identifier.Each of the first electronic device and the second electronic deviceincludes a wireless communication interface for wireless communicationtherebetween. The secure storage is configured to store one or moresecurity credentials associated with a user for authorized access to oneor more restricted access locations. Execution of the computer-readableinstructions by the processor of the first electronic device causes theprocessor to: detect a presence of the second electronic device within apredetermined proximity range of the first electronic device, based onan indication received from the second electronic device via therespective wireless communication interface; establish a communicationchannel between the first electronic device and the second electronicdevice via each wireless communication interface, responsive to thedetected presence of the second electronic device; receive the uniquedevice identifier from the second electronic device via thecommunication channel; determine whether the received unique deviceidentifier matches a predetermined identifier stored in the securestorage, to validate the second electronic device; receive user identityinformation from the user via the user interface; determine whether theuser identity information matches predetermined user identityinformation, to validate an identity of the user; determine whether thefirst electronic device and the second electronic device maintain apredefined connection state; and permit access to the one or moresecurity credentials stored on the secure storage when the identity ofthe user is validated, the second electronic device is validated and thepredefined connection state is maintained.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a functional block diagram of an example security system,according to an aspect of the present disclosure.

FIG. 2 is a functional block diagram of an example first electronicdevice of the system shown in FIG. 1, according to an aspect of thepresent disclosure.

FIG. 3A is a functional block diagram of an example second electronicdevice of the system shown in FIG. 1, according to an aspect of thepresent disclosure.

FIG. 3B is a side view diagram of an example wearable electronic devicewhich may be representative of the second electronic device shown inFIG. 3A, according to an aspect of the present disclosure.

FIG. 4 is a functional block diagram of an example registration server,according to an aspect of the present disclosure.

FIG. 5 is a functional block diagram of an example monitoring server,according to an aspect of the present disclosure.

FIGS. 6A and 6B are flowchart diagrams of an example method ofinitiating an authenticated state between first and second electronicdevices of the system shown in FIG. 1 to enable authorized access torestricted access locations, according to an aspect of the presentdisclosure.

FIG. 6C is a flowchart diagram of an example method of initiating anauthenticated state between first and second electronic devices of thesystem shown in FIG. 1 to enable authorized access to restricted accesslocations, according to another aspect of the present disclosure.

FIG. 7 is a flowchart diagram of an example method of operating thesystem shown in FIG. 1 for authorized access to a restricted accesslocation, according to another aspect of the present disclosure.

FIG. 8 is a flowchart diagram of an example method of operating thesystem shown in FIG. 1 for monitoring device usage in the authenticatedstate during access to various resources, according to an aspect of thepresent disclosure.

FIG. 9 is a flowchart diagram of an example method of registering a userfor the system shown in FIG. 1, according to an aspect of the presentdisclosure.

FIG. 10 is a functional block diagram of an example identity managementand security system, according to another aspect of the presentdisclosure.

FIGS. 11A and 11B are flowchart diagrams of an example method ofregistering a user for the system shown in FIG. 10, according to anaspect of the present disclosure.

FIGS. 12A and 12B are flowchart diagrams of an example method ofinitiating an identified state between first and second electronicdevices of the system shown in FIG. 10 to enable authorized access torestricted access locations, according to an aspect of the presentdisclosure.

FIG. 13 is a flowchart diagram of an example method of operating thesystem shown in FIG. 10 for authorized access to a restricted accesslocation, according to another aspect of the present disclosure.

FIG. 14 is a flowchart diagram of an example method of operating thesystem shown in FIG. 10 for recovering security credentials, accordingto an aspect of the present disclosure.

DETAILED DESCRIPTION

Users typically have a real identity, such as a national ID card or adriver's license, which can be confirmed by way of one or moreverification providers. Users may also have one or more virtualidentities, for accessing resources such as websites, applications,information, locations, etc. However, for virtual identities, eachresource (such as a website) may include a sign-up process that createsa separate identity each time a user registers. This may createunnecessary overhead and may be a deterrent for online commerce.Furthermore, with each cyber compromise, large volumes of identityinformation is being extracted and misused to target specific users. Asolution that is able to combine a user's real-world identity with thevirtual world identity while maintaining privacy is needed, but iscurrently unavailable.

Currently, many password storage solutions architectures include centralstorage of user specific master passwords that can be accessed by thesolution provider. These providers may protect the users by creatingstringent policies and may use external auditors to police theenforcement of these policies. However, if necessary, someone other thanthe user can access user specific passwords without the user'sknowledge. A solution where the architecture only allows the user toaccess the password without any backdoor or master password access isneeded but not available.

Users often use different operating platforms from differentmanufacturers. A common approach to access security credentials acrossall of these devices is to use a central storage mechanism for allsecurity credentials and synchronize the mechanism with all of thedevices. Once a password is entered to access this central mechanism,all of the security credentials may be accessible. While this may beconvenient for the user, it creates significant risk. Not only are allthe security credentials stored in one location, addresses of restrictedaccess locations (ARALs) may also be available within the samemechanism. If compromised, an attacker may obtain a list of all theuser's security credentials and ARALs. A solution that only maintains alocal copy of the security credentials, while keeping a separate centralrepository of all the ARALs is needed, but currently not available.

Many current authentication systems assume that once correct credentials(e.g., a user ID, a password, security question response(s), and/or arequest coming from a registered device) are provided, unrestrictedaccess may be granted and no further monitoring needs to be performed. Afundamental weakness in this approach is that, after access has beengranted, the identity of the user becomes unknown. Without re-confirmingthe user's identity, it may be difficult to determine whether the sameuser continues to access the system or whether another impersonator hastaken over access. An authentication solution that continuouslyre-confirms the identity of the user is needed, but is currentlyunavailable.

Existing two-factor or two-step authentication systems that use twoseparate hardware devices may be more challenging to compromise.However, some implementations of this type of authentication may beinconvenient for the user. For example, the user may carry a separatedevice (i.e., a USB key). The user may receive a separate code on theseparate device and then enter this code manually to obtain access. Amulti-factor (i.e., more than two-factor/two-step) authenticationsolution that does not require the user to perform manual tasks torepeatedly confirm their identity is needed, but is currently notavailable.

Keylogging is the most typically used approach taken by hackers to stealcredentials. If this vulnerability is exploited, any user that storescredentials centrally and accesses them via a password or typespasswords manually may become vulnerable to such attacks. Even two-stepor two-factor authentication systems require typing a password, andtherefore also makes them vulnerable to keylogging. A solution that doesnot require the user to use a physical keyboard to type in a password orother credentials is needed, but currently unavailable.

Intrusion detection systems (IDS) often analyze the “mass” movement ofdata and involves significant forensic analysis to determine whether thedata movement is a result of a cyber-attack or is typical user behavior.Currently, this process may take a long period of time (often days orweeks) and may involve a manual process. This may be disadvantageous.For example, the longer it takes to make a determination of acyber-attack, the higher the likelihood of significant and ongoing dataloss. A solution where the true identity of a user may be determined inreal-time so that a security team can instantaneously identifycompromised user accounts is needed, but unavailable.

Many authentication solutions that leverage handheld devices are oftenlimited to devices that have an operating system from the samemanufacturer. For example, Apple's iCloud Keychain® may operate on iOSor Mac OS X devices. A user may not be able to use iCloud Keychain® on aWindows device or an Android device. These types of proprietarysolutions may create a significant burden on the user as they remove theflexibility for the user to use any device, anywhere, anytime. Asolution that allows the user to access their authentication credentialson any system, anywhere, anytime, is needed, but currently notavailable.

Audit logs for access to systems or data are often maintained at anidentity access management (IAM) system (e.g., Microsoft ActiveDirectory), an application system (e.g., Oracle Financials) or a serviceprovider system (e.g., SalesForce) level. While this may be importantfor the administration of access and maintenance of each systemseparately, this approach fundamentally ignores the importance ofreal-time user centric analysis for determining whether the credentialsof a user have been compromised. A solution where audit logs aremonitored such that they may provide a universal view of user activityis needed, but is currently unavailable.

Many existing IAM solutions are organization specific and not userspecific. As users interact with more organizations, employers, banks,public transportation, home-office, car companies, etc., managingmultiple IAM systems has become more challenging. A user centric IAMsolution is needed but is currently not available. An IAM solution thatis user focused so that a user can securely access multipleorganizations that are unrelated to one another is needed, but is notavailable.

Leveraging biometrics may be convenient for security purposes, becausebiometric information (e.g., a fingerprint, a retina signature, aheartbeat signature, etc.) may always physically be with the user. Onthe other hand, once these are stolen, they cannot be replaced with anew fingerprint, new retina signature or a new heartbeat signature. Asolution where biometrics are leveraged for convenience (and locallystored to prevent against a massive breach of all user biometric data)but may not be a foundational element of security is needed, but is notavailable.

Existing authentication solutions are a) secure but not easy for useroperation or b) easy for user operation but not secure. A betterapproach is needed that is transparent to the user but may provide: twoor more factor authentication, decentralized storage of credentials forusers, the capability to differentiate between real users andimpersonators, an IAM solution that is use-centric (as opposed to beingorganization-centric), ease in registering for restricted accesslocations (RALs) (such as new websites) while protecting the user'sprivacy, and the ability to access RALs anywhere and anytime withouthaving to memorize passwords.

Generally described, aspects of the present disclosure relate to systemsand methods for providing authorized access to one or more restrictedaccess locations. The system may include a first electronic device and asecond electronic device. The first electronic device may be associatedwith a first unique device identifier. The first electronic device(and/or the second electronic device) may include a secure storageconfigured to securely store one or more security credentials associatedwith the user for the authorized access to the respective restrictedaccess locations. In some examples, the second electronic device mayinclude a wearable device that is a physically separate device from thefirst electronic device, and may be associated with a second uniquedevice identifier different from the first unique identifier.Description of embodiments is exemplary and not intended to limit theclaims.

The first electronic device may detect that the second electronic deviceis within a predetermined proximity range to the first electronicdevice, based on an electronic signal wirelessly received from thesecond device. Responsive to the detection, the first and second devicesmay be paired together, to form a bonded state, and establish acommunication channel therebetween. For example, the first and seconddevices may be paired and bonded according to a Bluetooth pairing andbonding protocol. In some examples, the communication channel mayinclude a secure communication channel, based on encryption/decryptionkeys known by the first and second electronic devices. After the firstand second electronic devices establish the communication channel, thefirst electronic device may validate the second electronic device, bydetermining whether the second unique device identifier matches apredetermined identifier stored in the secure storage. The firstelectronic device may also determine whether the first electronic deviceand the second electronic device maintain a predefined connection state.When the second electronic device is valid and the predefined connectionstate is maintained, the first and second devices may form a connectedstate.

In some examples, the first electronic device may receive authenticationinformation from the user via a user interface and determine whether theauthentication information for the user is valid. The authenticationinformation may be used to indicate whether the user is authorized touse the first electronic device and the second electronic device. Whenthe authenticated information is valid (and the devices have achievedthe connected state), the first and second devices may form anauthenticated state.

When the first and the second electronic devices are in theauthenticated state, the first electronic device may permit access tothe security credentials in the secure storage. Thus, access may bepermitted when the second electronic device is validated, the predefinedconnection state is maintained and the user is authenticated. Inoperation, when the first electronic device detects a request to accessa restricted access location (RAL), the security credentials for the RALare known to be stored in the secure storage, and the devices are in theauthenticated state, the first electronic device may be permitted toobtain and apply the credentials to the RAL. In some examples, the firstelectronic device may apply the credentials to the RAL without userinput. In some examples, the first electronic device may apply thecredentials to the RAL with some user input, such as by selecting anicon on a display screen. When the first and second electronic devicesare not in the authenticated state, access to the credentials may not bepermitted. Thus, when the two devices have achieved an authenticatedstate, security credentials locally stored on the first electronicdevice (and/or second electronic device) may be retrieved and used foraccess to RALs, without user input of a user ID/password and, in someexamples, without using any biometric information of the user.

In some examples, a wearable second electronic device may determinewhether the wearable device is coupled and/or secured to the user, andtransmit an indication to the first electronic device. When the wearabledevice is secured (coupled) to the user, the system may enter a securedstate. In some examples, the wearable device may detect coupling of thedevice to the user. In some examples, the wearable device may detectengagement of the wearable device (e.g., closure of a clasp). In someexamples, the connection and authentication modes are establishedresponsive to receipt of the indication by the first electronic device.In some examples, access to the stored credentials in the first (and/orsecond) electronic device may be permitted only when both the first andsecond electronic devices are in the secured state and in theauthenticated state.

In some examples, when the first and second electronic devices are inthe connected state, and prior to the request for access, the firstelectronic device may request user identification information from theuser, via a user interface (as opposed to authentication information).The user interface may include, without being limited to, a physicalkeyboard, a virtual keyboard, a camera, a microphone and/or a biometricinput device. The first electronic device may compare received useridentity information to predetermined user information to verify anidentity of the user. When the user's information is verified, thesystem may enter an identified state. The access to the securitycredentials on the secure storage may be permitted when the first andsecond electronic devices are both in the connected state and in theidentified state. The identity information may be verified directly onthe first electronic device and/or on one or more servers coupled to thefirst electronic device.

In some examples, the user identification information may include anestablished physical identity mechanism (EPIM). The EPIM may include,without being limited to, a government issued identity, a debit/creditcard, an identity card, an account number, an employee email address, anemployee ID, a customer ID, a supplier ID, etc. During registration ofthe first and second electronic devices, the user may be requested toprovide an EPIM, for example, via input using the first electronicdevice. A server coupled to the first electronic device may verify theEPIM (such as via a Government organization, a financial institution, atelecommunication operator, an employer, a 3rd party verificationservice, etc.).

In some examples, after the system is provided with authorized access tothe restricted access location, a server may periodically capture dataassociated with device usage. The captured data may indicate whether aparticular identified user, using a specific device, using a specificsession (e.g., specific browser/browser session, application/applicationsession) accessed a specific resource. The information may be used toidentify whether an authorized user or an imposter has taken over theresource.

The restricted access locations may include physical or virtuallocations, where access may only be granted via authenticationinformation (e.g., a physical key, a user ID/password, a code). Therestricted access locations may include websites, mobile applications,home/office appliances, home/office electronics, home/office physicalaccess points, etc.

The first electronic device may include any electronic device capable ofelectronic communication via a communication network and capable ofwireless communication with the second electronic device. For example,the first electronic device may include a mobile phone (including asmartphone), a computer (including a notepad computer, a laptopcomputer, a personal computer), a tablet, a smart watch, a multimediadevice (e.g., a car infotainment system, a home multimedia system suchas Amazon Echo®), a home automation system, an automated teller machine(ATM), a credit card/debit card payment reader, etc. The secondelectronic device may include any device capable of wirelesscommunication with the first electronic device. In some examples, thesecond electronic device may include a wearable device (e.g., a smartwatch, a fitness tracker, a health tracker, a specialized wearabledevice, etc.) The first and second electronic devices may include twophysically separate electronic devices where their individual hardwareidentifiers are unique and cannot be changed. Each device may store datasecurely, exchange data securely and communicate securely with otherelectronic devices.

FIG. 1 is a functional block diagram of example security system 100,according to aspects of the present disclosure. System 100 may includefirst electronic device 102 and second electronic device 104. Firstdevice 102 may be a physically separate device from second device 104.First and second devices 102, 104 may be configured to wirelesslycommunicate with each other via any suitable wireless communicationprotocol (e.g., such as via Bluetooth, nearfield communication (NFC),etc.). First device 102 may be configured to store first unique deviceidentifier (ID) 116 associated with first device 102 and authenticationidentifier (ID) 120. Second device 104 may be configured to store secondunique device identifier 118 associated with second device 104. In someexamples, second device 104 may be configured to store authenticationidentifier 120, instead of first device 102. In some examples, bothfirst device 102 and second device 104 may be configured to storeauthentication identifier. First device 102 is described further belowwith respect to FIG. 2. Second device 104 is described further belowwith respect to FIGS. 3A and 3B. Although the examples below illustrateBluetooth and NFC communication protocols, it may be appreciated thatthe systems and methods of the current disclosure are not limited tothese example protocols. Other non-limiting examples of wirelesscommunication protocols include radio frequency identification (RFID),WiFi, Worldwide Interoperability for Microwave Access (WiMAX), ZigBee,frequency division multiple access (FDMA), time division multiple access(TDMA), code division multiple access (CDMA), and long-term evolution(LTE).

First device 102 (and/or second device 104) may be configured tocommunicate with one or more restricted access locations (RALs) 108 viacommunication network 106. First device 102 may also be configured tocommunicate with registration server 110 during a registration process(described further below with respect to FIG. 9). Registration server110 may also transfer information from second device 104 via firstdevice 102 (or directly to second device 104). Registration informationmay be stored in registration database 112. Registration information mayinclude, for example, first unique identifier 116 associated with firstdevice 102, second unique identifier 118 associated with second device104 and any restricted access locations for authorized access by firstdevice 102. In some examples, the registration information may alsoinclude authentication ID 120. In some examples, registration server 110may also store user information, such as, without being limited to, userdevice details (e.g., device name, device model, media access control(MAC) information, an internet protocol (IP) address, an operatingsystem, etc.), any logs of user activity, user credentials back up data,user device certificate(s) (e.g., a public key), and user authenticationand/or user identification backup data.

System 100 may also include monitoring server 114 for periodicallymonitoring session information and device information during access tovarious resources by first device 102 (during an authenticated state)(or one or more further electronic devices (not shown) such as apersonal computer), described further below with respect to FIG. 8. Themonitored information may be used, for example, to monitor use of firstelectronic device 102, monitor use of second electronic device 104,monitor use of a further electronic device, monitor use of any RALsaccessed using security credentials 224 from secure internal storage(e.g., storage 204 and/or storage 304) and/or to identify whether anauthorized user or a fraudulent user (i.e., an imposter) is accessing aresource.

Collectively, system 100 may provide a continuous multi-factorauthentication (MFA) for access to RALs 108. The continuous MFA may usemultiple factors to authenticate a user and provide user access to RALs108 (e.g., described further below with respect to FIGS. 6A-6C and FIG.7), using first and second devices 102, 104. In addition, the continuousMFA repeatedly audits the provided access and this information(generated by the continuous MFA) may be used to prevent access tounauthorized users (described further below with respect to FIG. 8).

Although not shown in FIG. 1, in some examples, registration server 110and/or monitoring server 114 may be configured to directly communicatewith each of first electronic device 102 and second electronic device104. Registration server 110 and monitoring server 114 are describedfurther below with respect to FIGS. 4 and 5. Although registrationserver 110 and monitoring server 114 are shown as separate servers, insome examples, the functions of servers 110 and 114 may be included in asingle server.

As discussed above, RAL(s) 108 may include physical or virtuallocations, where access may only be granted via authenticationinformation (e.g., a physical key, a user ID/password, a code, acryptographic key). RAL(s) 108 may include, without being limited to,websites, mobile applications, home/office appliances, home/office/otherelectronics, vehicles, home/office/other physical access points (e.g.,building door(s), etc.), multimedia devices (e.g., vehicle infotainmentsystems, home multimedia systems, home automation systems, ATMs andcredit card/debit card payment readers.

FIG. 2 is a functional block diagram illustrating an example firstdevice 102 according to aspects of the present disclosure.Illustratively, first device 102 may include non-transitory memory 200,processor 202, secure internal storage 204 (also referred to herein assecure storage 204 or storage 204), wireless communication interface206, network interface 208, one or more audio/video input devices 210,encryptor/decryptor 214, battery 216 for powering first device 102,optional other input devices and sensors 218, optional biometric inputdevice(s) 220 and optional touch sensitive display system 222. Secureinternal storage 204 may be configured to store security credentials224, RAL(s) information 226 and security system information 228. Secureaccess application 212 may be stored in memory 200 and may containcomputer-implementable code for performing the operations describedherein. Security credentials 224 may be accessed in secure internalstorage 204 only when first device 102 and second device 104 are in anauthenticated state (described further below). Components of firstdevice 102 may communicate with each other via a communication and databus (not shown). In general, input devices 210, other optional devices218, optional biometric input devices 220 and optional display system222 may be referred to herein as a user interface.

Processor 202 may be configured to control one or more components offirst device 102 (i.e., non-transitory memory 200, secure internalstorage 204, wireless communication interface 206, network interface208, audio/video input device(s) 210, encryptor/decryptor 214, battery216, optional other input devices and sensors 218, optional biometricinput device(s) 220 and optional touch sensitive display system 222).Processor 202 may include, without being limited to, a microprocessor, acentral processing unit, an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) and/or a digital signalprocessor (DSP). Processor 202 may be configured to execute processinglogic for performing the operations described herein. In general,processor 202 may include any suitable special-purpose processing deviceor a general-purpose processing device specially programmed withprocessing logic to perform the operations described herein. In someexamples, processor 202 may be configured to execute secure accessapplication 212 to perform the operations described herein.

Memory 200 may include, for example, without being limited to, at leastone of a read-only memory (ROM), a random access memory (RAM), a flashmemory, a dynamic RAM (DRAM) and a static RAM (SRAM), storingcomputer-readable instructions (i.e., programming logic such as secureaccess application 212) executable by processor 202. In general, memory200 may include any suitable non-transitory computer readable storagemedium storing computer-readable instructions executable by processor202 for performing the operations described herein. Although one memory200 is illustrated in FIG. 2, in some examples, first device 102 mayinclude two or more memory devices (e.g., dynamic memory and staticmemory).

In some examples, memory 200 may include a data storage device storinginstructions (e.g., software) for performing any one or more of thefunctions described herein (including the predetermined operation modesas described herein). The data storage device may include any suitablenon-transitory computer-readable storage medium, including, withoutbeing limited to, solid-state memories, optical media and magneticmedia.

Security credentials 224 may represent security credentials associatedwith one or more RALs 108. Examples of security credentials 224 mayinclude, without being limited to, one or more of a user ID, a password(including a one-time password (OTP)), a predetermined code, an accesskey, a cryptographic key and a security question response. RAL(s)information 226 may represent any information associated with each RAL108 for which first device 102 (and/or second device 104) storessecurity credentials 228. For example, RAL(s) information 226 mayinclude list of one or more RALs 108 corresponding to securitycredentials 224 (and/or 328). In some examples, such as for virtuallocations, RAL information 226 may include a virtual address of RAL 108(e.g., for access to RAL 108 over network 106. Security systeminformation 228 may represent any information associated withestablishing an authorized state (or identified state as in system 1000of FIG. 10). Example security system information 228 may include,without being limited to, first unique device ID 116, authentication ID120 (or user identity indication 1022 in FIG. 10), second unique deviceID 118, validation code(s) (described further below),encryption/decryption keys for creating a secure communication channelbetween first and second devices 102, 104. In some examples, securitycredentials 224, RAL(s) information 226 and security system information228 may be stored in separate databases in secure storage 204. In someexamples, one or more of security credentials 224, RAL(s) information226 and security system information 228 may be combined into onedatabase in secure storage 204.

In some examples, secure storage 204 may include built-in internalstorage (such as hardware and/or software-based secure storage space)that is part of first device 102 and/or registration-generated storage(e.g., hardware and/or software-based secure storage space). In someexamples, built-in internal storage may be configurable according todevice manufacturer and/or owner specifications. In some examples, oneor more components of system 100 (such as registration server 110) maycontrol configuration of registration-generated storage. In general, thestorage configuration may include storage access and/or storageallocation.

Wireless communication interface 206 may be configured to wirelesslycommunicate with second device 104 (connected) via a wirelesscommunication channel. Wireless communication interface 206 may beconfigured to wirelessly communicate with second device 104 via anysuitable short-range wireless communication standard, such as, withoutbeing limited to, Bluetooth and NFC standards. Wireless communicationinterface 206 may be controlled by processor 202 to interact with seconddevice 104 such that information is passed between first device 102 andsecond device 104 (i.e., over a short-range or long-range wirelesscommunication channel).

Network interface 208 may be configured to communicate with restrictedaccess location(s) 108 and registration server 110 over communicationnetwork 106. Communication network 106 may include one or more privateand/or public networks.

First device 102 may include any compatible electronic device that cancommunicate wirelessly and interact with second device 104. Examples offirst device 102 may include, without being limited to, mobile phones,tablet computers and personal computers (e.g., desktop computers orlaptop computers). In some examples, first device 102 may include awearable device, such as, without being limited to, a smart watch, afitness tracker, a health tracker, jewelry (e.g., a necklace, anearring, etc.) and a specialized wearable device.

Although not shown, first device 102 may be configured to communicatewith a further electronic device (e.g., a tablet computer or personalcomputer) via wired communication, wireless communication (e.g., viawireless communication interface 206) and/or via network 106 (e.g., vianetwork interface 208). The user may use the further electronic deviceto provide various user input to first device 102, for example, forregistration of first and second devices 102, 104, for authentication ID120 (or user identity information with respect to FIG. 10), for securitycredentials 224, for RAL(s) information 226 and/or for accessing RAL(s)108. In some examples, first device 102 may obtain security credentialsfrom a further electronic device and/or may input security credentialsinto the further electronic device, when first and second devices 102,104 are in the authenticated state (or when first and second devices1002, 1004 are in the identified state described below with respect toFIGS. 12A and 12B).

In some examples, first device 102 may include audio/video inputdevice(s) 210 for receiving one or more user inputs from a user of firstdevice 102. Device(s) 210 may include, for example, one or more buttons,an alphanumeric input device, a cursor control device, a microphone, acamera and/or a display. The user input may, for example, be used toselect restricted access locations, to input authentication identifier120, and to register first device 102 and second device 104. Firstdevice 102 may also include any other suitable input devices and/orsensors 218 for accepting/capturing user input (e.g., motion, userposition, etc.) Although not shown, first device 102 may also includeany suitable user output device, such as a display, a loudspeaker, avibration sensor, etc.

In some examples, first device 102 may include optional touch sensitivedisplay system 222. Optional touch sensitive display system 222 may, forexample, be used to indicate prompts for user input and/or variousinformation during one or more predetermined operation modes. In someexamples, optional touch sensitive display system 222 may provide avirtual keyboard for user input. In general, first device 102 mayinclude any suitable user interface for capturing user input andproviding information to the user for operation of system 100 includingsecure access to RAL(s) 108.

Optional biometric input device(s) 220 may include any suitable inputdevice for capturing biometric data of a user. Example, biometric datamay include, without being limited to a fingerprint, a retina signature(i.e., eye scan data), a heartbeat signature and a voiceprint. In someexamples, optional biometric device(s) 220 may be used with system 100(FIG. 10) for verifying an identity of the user.

Encrypter/decryptor 214 may be configured to encrypt and decrypt datasent between first device 102 and second device 104 according toencryption/decryption keys stored in secure internal storage 204 (i.e.,as part of security system information 228). Encrypter/decryptor 214 mayalso be configured to encrypt and decrypt information sent toregistration server 110 and/or monitoring server 114 via network 106. Insome examples, encryptor/decryptor 214 may include a cryptographicengine for carrying out cryptographic operations such as encryption,decryption, public and/or private key generation, pseudo-random numbergeneration, digital signatures, etc. The cryptographic engine mayinclude software, hardware and/or a combination thereof for performingcryptographic operations using one or more cryptographic algorithms. Insome examples, the cryptographic engine may include a hardware device(e.g., a dedicated computer on a chip or a microprocessor) for carryingout cryptographic operations. In some examples, the cryptographic enginemay include a separate device (e.g., a co-processor) in electroniccommunication with processor 202. In some examples, the cryptographicengine may be integrated into processor 202 itself.

First device 102 may include any suitable hardware and/or softwarecomponents for performing the functions described herein.

FIG. 3A is a is a functional block diagram illustrating an examplesecond device 104 according to aspects of the present disclosure.Illustratively, second device 104 may include non-transitory memory 300,processor 302, optional secure internal storage 304 (also referred toherein as secure storage 304 or storage 304), wireless communicationinterface 306, optional network interface 307, optional battery 310 forpowering second device 104, optional physical locking mechanism 312,optional display/input device(s) 314, optional other input device(s) 316and optional encryptor/decryptor 318. In some examples, second device104 may include encryptor/decryptor 318. In other examples, seconddevice 104 may not include encryptor/decryptor 318. In some examples,second device 104 may include secure internal storage 304. In otherexamples, second device 104 may not include secure internal storage 304.In examples of second device 104 that do not include secure internalstorage 304, information described as being stored in storage 304 may bestored in memory 300. Components of second device 104 may communicatewith each other via a communication and data bus (not shown).

Secure internal storage 304 may be configured to store, for example,security information 328. Security information may include, withoutbeing limited to, second unique device identifier 118, validationcode(s), any secure access keys (described further with respect to FIG.6C) and encryption/decryption keys for a secure communication channelbetween first and second devices 102, 104. Although not shown, in someexamples, secure internal storage 304 may also store securitycredentials 224 and/or RAL(s) information 226 for one or more RALs 108.Accordingly, in some examples, access to security credentials 224 mayinclude access to security credentials 224 stored on first device 102and/or second device 104. Secure access application 308 may be stored inmemory 300 and may contain computer-implementable code for performingthe operations described herein.

In some examples, secure storage 304 may include hardware-based storagespace (e.g., an embedded secure element storage location) and/orsoftware-based secure storage. In some examples, secure storage 304 mayinclude built-in internal storage that is part of second device 104and/or registration-generated storage. In some examples, one or morecomponents of system 100 (such as registration server 110) may controlconfiguration of storage 304. In some examples, storage 304 may includebuilt-in storage that may or may not be configurable by component(s) ofsystem 100. For example, secure storage 304 may include built-in storagethat may not be accessible component(s) of system 100.

In some examples, encryptor/decryptor 318, similar toencryptor/decryptor 214, may include a cryptographic engine for carryingout cryptographic operations such as encryption, decryption, publicand/or private key generation, pseudo-random number generation, digitalcertificates, etc. In some examples, the cryptographic engine mayinclude a separate device (e.g., a co-processor) in electroniccommunication with processor 302. In some examples, the cryptographicengine may be integrated into processor 302 itself.

In general, display/input device(s) 314 and other optional inputdevice(s) 316 may be referred to herein as a user interface.Display/input device(s) 314 and optional input device(s) 316 mayrepresent any suitable device for capturing user input (e.g., amicrophone, a camera, button(s), an accelerometer, an alphanumeric inputdevice, a cursor control device, a touch-sensitive display, etc.) and/orone or more output devices (e.g., a display, a loudspeaker, a vibrationsensor, etc.). In some examples, second device 102 may include optionalnetwork interface 307, for direct communication with, for example,registration server 110 and/or monitoring server 114. In some examples,second device 102 may communicate directly with restricted accesslocation(s) 108 via optional network interface 307. Memory 300,processor 302, secure internal storage 304, wireless communicationinterface 306, optional network interface 307, and encryptor/decryptor318 are similar to memory 200, processor 202, secure internal storage204, wireless communication interface 206, network interface 208, andencryptor/decryptor 214 described above with respect to FIG. 2.

In some examples, second device 104 may include any compatible portableelectronic device that can communicate wirelessly and interact withfirst device 102. Examples of second device 104 may include, withoutbeing limited to, mobile phones, tablet computers and laptop computers.

In some examples, second device 104 may include a wearable device thatis capable of being coupled to the user (i.e., worn by the user). Forexample, the wearable device may include a smart watch, a fitnesstracker, a health tracker, a specialized wearable device configured asjewelry, etc. In some examples, a wearable second device 104 may includeoptional physical locking mechanism 312. Mechanism 312 may be configuredto detect whether second device 104 is coupled to and/or secured to theuser. For example, mechanism 312 may detect skin coupling of seconddevice 104 to the user. In some examples, mechanism 312 may detect otherbiometric data (e.g., a heartbeat, a pulse, respiration, etc.) todetermine whether second device 104 is coupled to and/or secured to theuser. As another example, mechanism 312 may detect closure or opening ofa physical locking device, such as a clasp. In some examples, processor302 may be configured to send a secured and/or unsecured indication tofirst device 102 based on coupling/non-coupling detection by optionalmechanism 312.

Second device 104 may include any suitable hardware and/or softwarecomponents for performing the functions described herein.

Referring to FIG. 3B, an example of a wearable second device 104 isshown. In some examples, second device 104 may include housing 320 forholding hardware and/or software components of second device 104 (suchas shown in FIG. 3A). Second device 104 may also include strap 322 forfixing second device 104 to a user and clasp 324 for securing seconddevice 104 to the user. In some examples, clasp 324 may include physicallocking mechanism 312 for detecting whether clasp 324 is secured.

FIG. 4 illustrates a functional block diagram of an example registrationserver 110 (or registration and verification server 1010 shown in FIG.10) in the example form of a computer system within which a set ofinstructions for causing the machine to perform any one or more of themethodologies discussed herein, may be executed. In some examples, themachine may be connected (e.g., networked) to other machines. Themachine may be any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine for performing the functions describe herein. Further, whileonly a single machine is illustrated, the term “machine” shall also betaken to include any collection of machines that individually or jointlyexecute a set (or multiple sets) of instructions to perform any one ormore of the methodologies discussed herein.

Example registration server 110 may include processing device 402,memory 406, data storage device 410 and network interface 412, which maycommunicate with each other via data and control bus 414. In someexamples, registration server 110 may also include input/outputinterface(s) 416.

Processing device 402 may include, without being limited to, amicroprocessor, a central processing unit, an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA), adigital signal processor (DSP) and/or a network processor. Processingdevice 402 may be configured to execute processing logic 404 (includingregistration application 418 or registration and verificationapplication 420) for performing the operations described herein. Ingeneral, processing device 402 may include any suitable special-purposeprocessing device or a processing device specially programmed withprocessing logic 404 to perform the operations described herein.

Memory 406 may include, for example, without being limited to, at leastone of a read-only memory (ROM), a random access memory (RAM), a flashmemory, a dynamic RAM (DRAM) and a static RAM (SRAM), storingcomputer-readable instructions 408 executable by processing device 402.In general, memory 406 may include any suitable non-transitory computerreadable storage medium storing computer-readable instructions 408executable by processing device 402 for performing the operationsdescribed herein. Although one memory device 408 is illustrated in FIG.4, in some examples, registration server 110 may include two or morememory devices (e.g., dynamic memory and static memory).

Registration server 110 may include network interface 412, forcommunication with other computers (including wired and/or wirelesscommunication) and/or for communication with network 106 (FIG. 1). Insome examples, registration server 110 may include input/outputinterface(s) (e.g., such as a display device, a user interface, etc.).

In some examples, registration server 110 may include data storagedevice 410 storing instructions (e.g., software including registrationapplication 418) for performing any one or more of the functionsdescribed herein. Data storage device 410 may include any suitablenon-transitory computer-readable storage medium, including, withoutbeing limited to, solid-state memories, optical media and magneticmedia.

The term “computer-readable storage medium” should be taken to include asingle medium or multiple media that store one or more sets ofinstructions. The term “computer-readable storage medium” shall also betaken to include any medium that is capable of storing or encoding a setof instructions for execution by the machine and that causes the machineto perform any one or more of the methodologies of the presentdisclosure.

Registration application 418 may be configured to perform the functionsdescribed herein with respect to registration server 110 of system 100(FIG. 1) and FIGS. 6-9 and 14. Registration verification application 420may be configured to perform the functions described herein with respectto registration and verification server 1010 of system 1000 (FIG. 10)and FIGS. 11-14.

FIG. 5 illustrates a functional block diagram of an example monitoringserver 114 (or monitoring server 1014 shown in FIG. 10) in the exampleform of a computer system within which a set of instructions for causingthe machine to perform any one or more of the methodologies discussedherein, may be executed. Example monitoring server 114 may includeprocessing device 502, memory 506, data storage device 510 and networkinterface 512, which may communicate with each other via data andcontrol bus 514. In some examples, monitoring server 114 may alsoinclude input/output interface(s) 516. Processing device 502, memory 506storing computer-readable instructions 508 executable by processingdevice 502, data storage device 510 and network interface 512 aresimilar to processing device 402, memory 406, data storage device 410and network interface 412 (FIG. 4), except that processing device 502may be configured to execute processing logic 504 (including monitoringapplication 418) for performing monitoring functions described withrespect to FIG. 8). Although servers 110 and 114 are shown as separatemachines, functions of servers 110 and 114 may be performed by onemachine or may be distributed among multiple machines.

Referring next to FIGS. 6-9, flow chart diagrams are shown representingexample operations of system 100 including: initiating an authenticatedstate (FIGS. 6A-6C), operation of system 100 for authorized access to arestricted access location (FIG. 7), operation of system 100 formonitoring authorized use of first and second devices 102, 104 (and insome examples, use of a further electronic device) (FIG. 8) andregistration of a user for system 100 (FIG. 9). In FIG. 6-9, it isunderstood that some of the steps may be performed by system 100concurrently with other steps or a combination of steps, or may beperformed in a different sequence than shown. It will also be understoodthat the steps shown in FIGS. 6-9 may be implemented by computer programinstructions provided to a processor, including, for example, processor202 executing secure access application 212, processor 302 executingsecure access application 308, processing device 402 executingregistration application 418 and processing device 502 executingmonitoring application 518, respectively. The examples illustrated belowgenerally describe the configuration where first device 102 is incommunication with registration server 110 and first device 102 includessecure internal storage 204. It is understood that these arenon-limiting examples, and that, in some examples, the illustratedprocesses may be performed where second device 104 is communication withregistration server 110 and/or second device 104 includes secureinternal storage 304.

FIGS. 6A-6B are flow chart diagrams of an example method of initiatingan authenticated state between first device 102 and second device 104,to enable authorized access to restricted access locations. At step 600,first device 102 may detect a presence of second device 104 within apredetermined proximity range of first device 102, for example byprocessor 202 using wireless communication interface 206. For example,first device 102 may detect a predetermined indication (e.g., a wirelesssignal) indicating second device 104. At step 602, first device 102 mayautomatically pair with second device 104 to form a bonded state. Forexample, first device 102 and second device 104 may exchange information(e.g., input/output capabilities) via a respective wirelesscommunication interfaces 206, 306 and respective processors 202, 302. Insome examples, first and second devices 102, 104 may form a bonded stateaccording to a Bluetooth pairing and bonding protocol. In general, atstep 602, first and second devices 102, 104 may establish a wirelesssecure communication channel therebetween, using encryption/decryptionkeys stored in secure storage 204 (or 304) or generated dynamicallybased on the specific wireless communication protocol. Thus, allsubsequent communication between first and second devices 102, 104 maybe performed via the secure (i.e., encrypted) communication channel.

In some examples, step 602 proceeds to optional step 604. At optionalstep 604, second device 104 may determine whether second device 104 issecured (or coupled) to a user. For example, processor 302 may receivean indication from optional physical locking mechanism 312 indicatingthat second device 104 is secured to the user. In other examples,processor 302 may detect that second device 104 is in contact with theuser, such as using detected skin contact or other biometric data. Whenprocessor 302 of second device 104 determines that second device 104 isnot secured to the user, optional step 604 proceeds to step 602. Whenprocessor 302 of second device 104 determines that second device 104 issecured to the user, optional step 604 may proceed to optional step 606.At optional step 606, second device 104 may send a secured indication tofirst device 102, for example, via respective wireless communicationinterfaces 206, 306. At optional step 608, processor 202 at first device102 may form a secured state, responsive to the received securedindication (step 606). Optional step 608 may proceed to step 610.

In some examples, initiation of the authenticated state may not includeformation of a secured state. In these examples, step 602 may proceed tostep 610. At step 610, processor 202 of first device 102 may transmit arequest for device validation information to second device 104, viawireless communication interface 206. At step 612, responsive to therequest (step 610), first device 102 may receive second unique device ID118 and a validation code from second device 104.

The validation code may be one of one or more validation codes generatedby registration server 110 and sent to first device 102 and subsequentlytransmitted to second device 104 during a registration process (shown inFIG. 9). For example, a plurality of validation codes may be sent tosecond device 104 where each validation code may be valid for apredetermined time period (e.g., a time to live). In some examples,second device 104 may sequentially select and send one of the pluralvalidation codes that is currently valid (based on the predeterminedvalid time period). In some examples, second device 104 may receive andstore one validation code from first device 102 that may be periodicallyupdated by first device 102 (such as in optional step 626).

At step 614, processor 202 may compare the received second unique deviceID 118 to a predetermined ID stored in secure internal storage 204(i.e., as part of security system information 228). At step 616,processor 202 may compare the received validation code to a predefinedcode stored in secure internal storage 204 (i.e., as part of securitysystem information 228).

At step 618, processor 202 of first device 102 may determine whether thereceived second unique ID 118 matches the predetermined ID. Whenprocessor 202 determines that the received second unique ID 118 matchesthe predetermined ID, steps 618 proceeds to step 620. When processor 202determines that the second unique ID 118 does not match thepredetermined ID, step 618 proceeds to step 610.

At step 620, processor 202 of first device 102 determines whether thereceived validation code is valid, based on whether the receivedvalidation code matches the predefined code. When the receivedvalidation code is valid, step 620 proceeds to step 622. When processor202 determines that the received validation code is invalid, step 620proceeds to step 610.

At step 622, processor 202 of first device 102 determines whether apredefined connection state between first and second devices 102, 104 ismaintained over the secure communication channel. The predefinedconnection state may include, without being limited to, a persistentconnection (i.e., a connection where first device 102 and/or seconddevice 104 may immediately detect a broken connection), an intermittentconnection (i.e., a connection based on a user action) and/or a periodicconnection (i.e., a connection based on a predetermined period of time)for which secure communication can be maintained between first andsecond devices 102, 104. When processor 202 of first device 102determines that the predefined connection state is maintained, step 622proceeds to optional step 624. When processor 202 determines that thepredefined connection state is not maintained, step 622 proceeds to step602.

At optional step 624, first device 102, may confirm that second device104 is secured to the user. For example, processor 202 of first device102 may request that second device 104 send a secured indication tofirst device 102. In other examples, processor 202 may assume thatsecond device 104 is secured to the user based on the secure indicationreceived in step 606, unless second device 104 sends a furtherindication to first device 102 that second device 104 is not secured tothe user. When processor 202 of first device 102 determines that seconddevice 104 is secured to the user, optional step 624 proceeds tooptional step 626. When processor 202 determines that second device 104is not secured to the user, optional step 624 may proceed to step 602.

At optional step 626, processor 202 may generate and send a newvalidation code to second device 104 (that is also stored in securestorage 204 of first device 102). Step 626 may occur in those exampleswhere first device 102 may periodically generate and send a newvalidation code to second device 104. Optional step 626 may proceed to628.

At step 628, first device 102 may form a connected state with seconddevice 104. Thus, when first and second devices 102, 104 are determinedto be in the connected state, a secure communication channel existsbetween the devices (102, 104), a predefined communication state ismaintained, and the second device information has been validated byfirst device 102. Step 628 proceeds to step 630 (FIG. 6B).

At step 630 (FIG. 6B), first device 102 may generate a request forauthentication information via a user interface on first device 102. Forexample, processor 202 may request the input of authenticationinformation via touch sensitive display system 222. At step 632, firstdevice 102 may receive authentication information from the user via theuser interface. At step 634, processer 202 may compare the receivedauthentication information to predetermined information stored in secureinternal storage 204. At step 636, processor 202 may determine whetherthe received authentication information is valid (based on step 634).

When processor 202 determines that the received authenticationinformation is not valid, step 636 proceeds to step 638. At step 638,processor 202 may deny access to security credentials 224 stored insecure internal storage 204. Step 638 may proceed to step 628 (or step668) such that the system 100 returns to the connected (but notauthenticated) state.

When processor 202 determines that the received authenticationinformation is valid, step 636 proceeds to step 640. At step 640,processor 202 forms the authenticated state. In general, thepredetermined information for authentication may be generated during theregistration process (FIG. 9). The identification information may beused to confirm that the user has previously registered and isauthenticated to use system 100 for secure access to RALS 108 using acombination of first and second devices 102, 104.

At step 642, processor 202 of first device 102 may permit access tosecurity credentials 224 in secure internal storage 204, when system 100is in the authenticated state. At step 644, system 100 may continue inthe authenticated state as long as the predefined connection statebetween first and second device 102, 104 is maintained and, optionally,the secured state is maintained.

In general, FIGS. 6A and 6B describe a method for initiating anauthenticated state when second device 104 is capable of operating in abattery dependent state. When second device 104 does not include battery310 and/or battery 310 is not sufficiently powered, system 100 mayinitiate an authenticated state using a proximity dependent transmissionprotocol (e.g., near field communication (NFC)). FIG. 6C (in combinationwith FIG. 6A) illustrates an example of a proximity dependent method forinitiating an authenticated state between first device 102 and seconddevice 104.

At step 650, processor 202 of first device 102 detects a presence ofsecond device 104 within a predetermined proximity range of first device102. For example, when second device 104 is within the predeterminedproximity range, first device 102 may power second device 104, e.g., viaa NFC protocol. Responsive to being powered up by first device 102,second device 104 may transmit a predetermined indication (e.g., awireless signal) indicating second device 104. First and second devices102, 104 may then create a communication channel (while second device104 is within the predetermined proximity range).

At step 652, processor 202 of first device 102 may generate one or moreaccess keys with a predefined time to live. At step 654, processor 202of first device 102 may store the access key(s) in secure internalstorage 204 of first device 102 (e.g., as part of security systeminformation 228). At step 656, processor 202 of first device 102 maysend a copy of the access key(s) to second device 104 for storage ininternal storage 304, for example, using short-range transmission (e.g.,NFC) via respective wireless communication interfaces 206, 306.

At step 658, processor 202 of first device 102 may detect an access keyfrom second device 104, when second device 104 is within thepredetermined proximity range of first device 102, for example, viashort-range transmission. At step 660, processor 202 may compare thedetected access key from second device 104 with the stored access key insecure internal storage 204, to determine whether the detected accesskey is valid.

When processor 202 determines, at step 662, that the detected access keyis not valid, step 662 proceeds to 664, and the connected state may bedenied. In some examples, step 664 may proceed to step 650.

When processor 202 determines, at step 662, that the access key isvalid, step 662 proceeds to step 666. At step 666, processor 202 offirst device 102 may determine whether the time to live in the detectedaccess key is valid. When the time to live is not valid, step 666 mayproceed to step 664. When processor 202 determines, at step 666, thatthe time to live is valid, step 666 may proceed to step 668, and firstand second devices 102, 104 may form a connected state. Step 668proceeds to step 630 (FIG. 6B). Processor 202 of first device 102 maythen perform steps 630-644, as described above with respect to FIG. 6B,to initiate the authenticated state for a proximity dependent seconddevice 104. FIG. 6C illustrates an example proximity dependent methodfor initiating an authenticated state. In another example, access key(s)may be generated by first device 102 and transferred to second device104 each time second device 104 is initially detected within thepredetermined proximity range of first device 102 (step 650). Thegenerated access key(s) may be used to form a connected state for aslong as the second device 104 remains in proximity of first device 104,without assigning a time to live to the access key(s).

Referring next to FIG. 7, a flow chart diagram of an example method ofoperating system 100 for authorized access to a restricted accesslocation is shown. At step 700, first device 102 may detect that accessto a restricted access location is being requested. In some examples,the requested access may be requested directly by first device 102. Insome examples, the requested access may be by a further electronicdevice coupled to first electronic device 102. For example, processor202 may determine that a user is attempting to access a particularwebsite or application that requires input of security credentials 224.At step 702, processor 202 of first device 102 may determine whether RALinformation 226 related to the particular restricted access location isstored in secure internal storage 204 (and/or 304).

When it is determined, by processor 202, that RAL information 226 forthe particular restricted access location is not stored in securestorage 204, step 702 may proceed to step 704. At step 704, a user mayenter the security credentials manually, such as via a user inputdevice.

When processor 202 determines, at step 702, that the associated RALinformation 226 is stored in secure storage 204, step 702 may proceed tostep 706. At step 706, processor 202 may confirm whether first andsecond devices 102, 104 are in the authenticated state. When it isdetermined that first and second devices 102, 104 are not in theauthenticated state, step 706 may proceed to step 704.

When it is determined, at step 706, that first and second devices 102,104 are in the authenticated state, step 706 may proceed to step 708. Atstep 708, processor 202 may permit access to security credentials 224and may obtain security credentials 224 from secure internal storage 204(and/or 304). At step 710, processor 202 may apply the obtained securitycredentials to gain access to the particular restricted access location.

As discussed above, RAL(S) 108 may include physical or virtuallocations. FIG. 7 (and FIG. 13) may also be applied to a physicallocation, such as a physical access point (e.g., a door). Thus, at step710 (or step 1310), application of the obtained security credentials(while in an authenticated state) may cause a locking mechanism at thephysical access point to disengage, thereby permitting access to thephysical access point.

Referring next to FIG. 8, a flow chart diagram of an example method ofoperating system 100 is shown for monitoring usage of first electronicdevice 102 in the authenticated state during access to variousresources. At step 800, first device 102 may detect that access to arestricted access location has been initiated (e.g., at step 710 in FIG.7). At step 802, first device 102 may confirm that first and seconddevices 102, 104 are still in the authenticated state. When first device102 determines, at step 802, that first and second devices 102,104 arenot in the authenticated state, first device 102 may terminate access tosecurity credentials 224 on first device 102 (step 804).

When first device 102 determines, at step 802, that first and seconddevices 102, 104 are in the authenticated state, step 802 may proceed tostep 806. At step 806, first device 102 may generate and transmit adevice usage message to access monitoring server 114. The device usagemessage may include device usage information including, for example,first unique device identifier 116, a timestamp, an indication thatfirst and second devices 102, 104 are in the authenticated state, andthat first device 102 is currently being used to perform a task. In someexamples, the device usage information may include information regardinga current resource being accessed by first device 102. In some examples,the device usage information may include device information of a furtherelectronic device being used to perform a task.

At step 808, monitoring server 114 may store the device usageinformation, including a receipt in the device usage message in adatabase.

At step 810, first device 102 may periodically transmit a device usagemessage to monitoring server to indicate the current device usageinformation. At step 812, monitoring server 114 may store the deviceusage information in the currently received device usage message(transmitted at step 810).

The device usage information may be used to identify whether the firstand second devices 102,104 continue to be used to perform tasks,maintain an authenticated state, access one or more resources and toconfirm that an individual access resources continues to be theauthorized user (as opposed to an imposter). One or more organizationsmay access the monitoring information at any suitable point in time todetect fraudulent usage (i.e., differentiate between a real user and animposter). Although FIG. 8 is described with respect to first device 102generating and transmitting device usage messages (steps 806, 810), insome examples, second device 104 may generate and transmit usagemessages to monitoring server 114, such as when second device 104includes network interface 307.

Referring next to FIG. 9, a flow chart diagram is shown of an examplemethod of registering a user for system 100. At step 900, a registrationapplication may be initiated on first device 102 via communication withregistration server 110 over network 106. In some examples, theregistration application may be initiated directly on first device 102.In some examples, the registration application may be initiated on firstdevice 102 via a further electronic device (e.g., a laptop computer).

At step 902, first device 102 may be wirelessly paired with seconddevice 104, for example, by positioning second device 104 within apredetermined proximity range of first device 102 to form a bonded state(e.g., such as via a Bluetooth protocol).

At step 904, first and second devices 102, 104 may create and exchangeencryption/decryption keys between each other. At step 906, first andsecond devices 102, 104 may create a secure communication channel usingthe encryption/decryption keys (in step 904). In some examples at step906, first electronic device 102 may receive encryption/decryption keysgenerated by registration server 110, may create a secret key from thereceived keys and transmit the secret key to second device 104. At step906, first and second devices 102, 104 may create the securecommunication channel using the secret key. All further communicationbetween first device 102 and second device 104 may be performed usingthe secure communication channel according to the encryption/decryptionkeys created between first and second devices 102, 104.

At step 908, registration server 110 may cause secure storage areas 204,304 to be created on respective first device 102 and second device 104.At step 910, first electronic device 102 may obtain second unique deviceID 118 from second device 104 and transmit the first unique device 116and second unique device ID 118 to registration server 110 via network106. At step 912, registration service 110 may store the first andsecond unique device IDs 116, 118 on registration database 112. At step912, registration server 110 may also send one or more validation codesto first device 102 and/or second device 104. Transmission of thevalidation code(s) to at least one of first device 102 and second device104 may depend, for example, on which of first and second devices 102,104 are in communication with registration server 110.

At step 914, first device 102 may store the received validation code(s)in a secure area (i.e., secure internal storage 204). At optional step916, the validation code(s), received from registration server 110, maybe stored in a secure area (i.e., secure internal storage 304) of seconddevice 104, for example when second device 104 includes secure internalstorage 304. At optional step 918, first electronic device 102 mayreceive encryption/decryption keys generated by registration server 110and transmit the received keys to second device 104.

At step 920, first device 102 may create authentication identifier 120associated with the user, and store authentication identifier 120 in oneor more secure areas (i.e., secure internal storage 204 and/or 304) onfirst and/or second devices 102, 104. Authentication identifier 120 mayauthorize the user for authorized access to RALs 108 using system 100(in the authenticated state) for the combination of first device 102 andsecond device 104. Authentication identifier 120 may be selected by theuser, for example, via a user interface of first device 102 (or via auser interface on a further electronic device coupled to first device102). In some examples, authentication identifier 120 may be selected byregistration server 110. The selected authentication identifier 120 maybe provided to first electronic device 102 and may be indicated to theuser via a user interface of first device 102.

At step 922, first device 102 may create a personal user ID and presentthe personal user ID to a user (e.g., via a use interface of firstdevice 102). In some examples, the personal user ID may include a randomnumber generated multi-bit key (e.g., an 8 bit key, a 16 bit key, a 24bit key, etc.). In some examples, first device 102 may create andpresent the personal user ID to a user, without storing the personaluser ID in either of the secure storage areas (i.e., 204 and/or 304) offirst device 102 and second device 104. The user may manually store thepresented personal user ID (e.g., by manually entering the personal userID into a paper record or into an electronic record). The personal userID may be used for recovery of security credentials (described furtherbelow with respect to FIG. 14). Because the personal user ID may bepresented to the user without being stored in the secure storagearea(s), the user (and other non-authorized users) may be prevented fromaccess to the personal user ID except when the ID is presented to theuser at step 922. Thus, the user is only able to view the personal userID during registration, and may use the manually stored ID (e.g., in thepaper and/or electronic record) for recovery. In some examples, thepersonal user ID may be stored in another storage location separate fromfirst and second devices 102, 104. In some examples, the personal userID may be stored in another storage location on first device 102 and/orsecond device 104.

At step 924, first device 102 may receive a selection of one or morerestricted access locations for storage in first device 102. In someexamples, the selected restricted access location(s) may be inputdirectly into first device 102 via a user interface. In some examples,the selected restricted access location(s) may be provided to firstdevice 102 by a further electronic device. At step 926, first device 102may receive security credentials for the respective restricted accesslocation(s) (either directly or indirectly via a further electronicdevice).

At step 928, the received restricted access location(s) and securitycredentials may be stored in one or more secure areas of secure internalstorage 204 and/or 304. At step 930, the restricted access locations(received in step 924), the security credentials (received in step 926)and the authentication identifier (created in step 920), may be sent toregistration server 110 via first device 102 over network 106 forstorage in registration database 112. In step 930, first device 102 mayencrypt both the security credentials and the authentication identifierprior to transmission (e.g., via encryptor/decryptor 214).

Referring next to FIG. 10, a functional block diagram of exampleidentity management and security system 1000 is shown, according toaspects of the present disclosure. System 1000 may include firstelectronic device 1002 and second electronic device 1004. First device1002 (and/or second device 1004) may be configured to communicate withone or more RALs 1008 via communication network 1006. First device 1002may also be configured to communicate with registration and verificationserver 110 during a registration process (described further below withrespect to FIGS. 11A and 11B). Registration and verification server 1010may be configured to communicate with optional one or more third partyverification provider(s) 1012 via network 1006. System 1000 may alsoinclude monitoring server 1014 for periodically monitoring sessioninformation and device information during access to various resources byfirst device 1002 (during an identified state). First device 1002 may beconfigured to store first unique device ID 1016 associated with firstdevice 1002 and user identity information 1022. Second device 1004 maybe configured to store second unique device ID 1018 associated withsecond device 1004. Although not shown in FIG. 10, in some examples,registration server 1010 and/or monitoring server 1014 may be configuredto directly communicate with each of first electronic device 1002 andsecond electronic device 1004.

System 1000 is similar to system 100 (FIG. 1), except that system 100may be configured to form an authenticated state (based onauthentication identifier 120), whereas system 1000 may be configured toform an identified state (based on user identity verification). Thus, insystem 1000, access to security credentials 224 in first device 1002 maybe permitted when the user's identity is verified. This is in contrastto permitted access to security credentials 224 when it is confirmedthat the user has registered with system 100 (i.e., authenticated).

First device 1002, second device 1004, network 1006, RAL(s) 1008,registration and verification server 1010, monitoring server 1014 andregistration database 1020 are similar to respective first device 102,second device 104, network 106, RAL(s) 108, registration andverification server 110, monitoring server 114 and registration database120 (FIG. 1). Although registration and verification server 1010 andmonitoring server 1014 are shown as separate servers, in some examples,the functions of servers 1010 and 1014 may be included in a singleserver.

First device 1002 is different from first device 102 (FIG. 1) in thatfirst device 1002 may store user identity information 1022 in secureinternal storage 204 (e.g., as part of security system information 228),and may perform steps to verify the user's identity (either directly onfirst device 1002, via communication with registration and verificationserver 1010, third party verification provider(s) 1012 or anycombination thereof) (described further below with respect to FIGS. 12Aand 12B). Although the examples below describe storing user identityinformation 1022 in secure storage 204 of first device 1002, and usingthe user identity information 1022 stored on first device 1002 forverifying the user's identity, in some examples, user identityinformation 1022 may be stored in secure internal storage 304 of seconddevice 1004 and used to verify a user's identity. In some examples, useridentity information 1022 may be stored on both secure storage 204 offirst device 1002 and secure storage 304 of second device 1004.

Registration and verification server 1010 is different from registrationserver 110 (FIG. 1) in that server 1010 may verify the user's identityduring a registration process (described in FIGS. 11A and 11B) and, insome examples, during formation of the identified state for access tosecurity credentials 224 on first device 1002 (described in FIGS. 12Aand 12B).

Although not shown with respect to system 1000, first device 1002 andmonitoring server 1014 may also monitor and store device usageinformation, as described in FIG. 8. Monitoring server 1014 is differentfrom monitoring server 114 in that server 1014 may store identifiedstate information as opposed to authenticated state information inreceived device usage messages (described in FIG. 8). Collectively,system 1000 may also provide a continuous multi-factor authentication(MFA) for access to RALs 1008. The continuous MFA in system 1000 usesmultiple factors to identify a user and provide user access to RALs 108(e.g., described further below with respect to FIGS. 12A-12C and FIG.13) using first and second devices 102, 104. In addition, the continuousMFA repeatedly audits the provided access and this information(generated by the continuous MFA) may be used to prevent access tounauthorized users via monitoring server 1014.

System 1000 may validate user identify information that relates to theuser's real identity. In general, the user identification informationmay include an established physical identify mechanism (EPIM). The EPIMmay include any suitable mechanism, including, without being limited to,a government issued identity, a debit/credit card, an identity card, anaccount number, an employee email address, an employee ID, a customerID, a supplier ID, etc. During registration of first and second devices1002, 1004, the user may be requested to provide an EPIM, for example,via input using first device 1002. Server 1010, during registration, mayverify the EPIM either directly or via communication with optional thirdparty verification prover(s) 1012 (such as via a governmentorganization, a financial institution, a telecommunication operator, anemployer, a customer, a supplier, a private entity, a 3rd partyverification service, etc.). In some examples, during formation of theidentified state (FIGS. 12A and 12B), server 1010 directly and/or viaoptional provider(s) 1012 may also verify the EPIM of the user. In someexamples, user identity indication 1022 stored on first device 1002 mayinclude a multi-digit PIN associated with the EPIM (rather than the EPIMdirectly). The PIN may be confirmed during the registration process.

Referring next to FIGS. 11-14, flow chart diagrams are shownrepresenting example operations of system 1000 including: registrationof a user for system 1000 (FIGS. 11A and 11B), initiating an identifiedstate (FIGS. 12A and 12B), operation of system 1000 for authorizedaccess to a restricted access location (FIG. 13), and operation ofsystem 1000 for recovering security credentials (FIG. 14). In FIG.11-14, it is understood that some of the steps may be performed bysystem 1000 concurrently with other steps or a combination of steps, ormay be performed in a different sequence than shown. It will also beunderstood that the steps shown in FIGS. 11-14 may be implemented bycomputer program instructions provided to a processor, including, forexample, processor 202 executing secure access application 212,processor 302 executing secure access application 308, processing device402 executing registration application 420 and processing device 502executing monitoring application 518, respectively. The examplesillustrated below generally describe the configuration where firstdevice 1002 is communication with registration server 1010 and firstdevice 1002 includes secure internal storage 204. It is understood thatthese are non-limiting examples, and that, in some examples, theillustrated processes may be performed where second device 1004 iscommunication with registration server 1010 and/or second device 1004includes secure internal storage 304.

Referring to FIGS. 11A and 11B, flow chart diagrams are shown of anexample method of registering a user for system 1000. Steps 1100-1112are similar to steps 900-912 in FIG. 9, described above. Step 1114 issimilar to step 914 and optional step 916 in FIG. 9, described above.

At step 1116, server 1010, via first device 1002, may request user inputof the user's identity information. The user identity information mayinclude one or more EPIMs. In some examples, the user identityinformation may also include biometric information (e.g., a fingerprint,an eye scan, an image of the user, a voiceprint of the user, etc.). Theuser identity information may be provided via a suitable user interface,including a physical keyboard, a virtual keyboard, a camera, biometricinput device 220, etc.

At step 1118, server 1010 may receive the user identity informationinput via first device 1002, for example, over network 1006. At step1120, server 1010 may verify the received user identify informationagainst established information associated with the user. Server 1010may directly verify the identity information and/or verify the identifyvia one or more third party verification providers 1012.

At step 1122, server 1010 may determine whether the user's identity isverified. When server 1010 determines, at step 1122, that the identityis not verified, step 1122 may proceed to step 1124, and registrationmay be denied by server 1010. At optional step 1126, server 1010 mayrequest video-based identity confirmation if the identity cannot beverified at step 1122. If the video-based identity confirmation (step1126) is verified, optional step 1126 may proceed to step 1130. If thevideo-based identity confirmation cannot be verified, optional step 1126may proceed to step 1124. At optional step 1128, server 1010 mayblacklist devices and identity information when the identity cannot beverified at step 1120 (for example, if multiple attempts at registrationfail).

When server 1010 verifies the user's identity information, step 1122 mayproceed to step 1130. At step 1130, first device 1002 may store at leasta portion of the identity information (received at step 1118) as useridentity indication 1022 in secure storage 204. For example, useridentity indication 1022 may include a multi-digit PIN associated withone or more EPIMs, a portion of EPIM information (i.e., less than all ofthe EPIM information), biometric information or any combination thereof.In some examples, storing a portion of the identity information on firstdevice 1002 may be optional.

At step 1132, first device 1002 may create a global identifier (ID) forthe user and store the global ID in secure storage area 204 and/or 304(for example, depending upon which of first and second devices 1002,1004 include a secure storage area). In some examples, the global IDincludes a random number generated multi-bit key (e.g., an 8 bit key, a16 bit key, a 24 bit key, etc.). In some examples, a global ID may alsobe assigned to a user during registration of system 100 (described withrespect to FIG. 9 above). At step 1134, first device 1002 may create apersonal user ID and present the personal user ID on first device 1002(for example, on a user interface of first device 1002). In someexamples, the personal user ID may include a random number generatedmulti-bit key (e.g., an 8 bit key, a 16 bit key, a 24 bit key, etc.).First device 1002 may associate the personal user ID with the global ID.In some examples, the personal user ID may be used to decrypt the globalID. In some examples, first device 1002 may create and present thepersonal user ID to a user, without storing the personal user ID ineither of the secure storage areas (i.e., 204 and/or 304) of firstdevice 1002 and second device 1004. As discussed above, the user maymanually store the personal user ID in a paper and/or electronic record,for recovery of security credentials (described further below withrespect to FIG. 14). In some examples, the personal user ID may bestored in another storage location separate from first and seconddevices 1002, 1004. In some examples, the personal user ID may be storedin another storage location on first device 1002 and/or second device1004. Step 1134 may proceed to step 1136 (FIG. 11B).

Steps 1136-1142 (FIG. 11B) are similar to steps 918-928 (described abovewith respect to FIG. 9). At step 1144, the RAL(s), security credentialsand global ID may be sent to registration server 1010 via first device1002 over network 1006 for storage in registration database 1012. Instep 1144, first device 1002 may encrypt both the security credentialsand the global ID prior to transmission (e.g., via encryptor/decryptor214).

Referring to FIGS. 12A and 12B, example flow chart diagrams are shownillustrating a method of initiating an identified state between firstdevice 1002 and second device 1004 of system 1000 to enable authorizedaccess to restricted access locations. In FIG. 12A, steps 1200-1228 aresimilar to steps 600-628 in FIG. 6A described above. In FIG. 12A, step1228 proceeds to step 1230 (FIG. 12B).

At step 1230, first device 1002 may generate a request for user identityinformation via a user interface on first device 1002. For example,processor 202 may request the input of identity information via, forexample, touch sensitive display system 222. At step 1232, first device1002 may receive the requested identity information from the user viathe user interface (for example, via touch sensitive display system 222,a camera, biometric input device(s) 220, etc.).

At step 1234, processor 202 of first device 1002 may compare thereceived identity information to user identity indication 1022 stored insecure internal storage 204. At optional step 1236, the receivedidentity information may be validated by server 1010 (directly or incombination with third party verification provider(s) 1012. In someexamples, step 1234 may not be performed, and only server 1010 (directlyor indirectly) may validate the received identity information.

At step 1238, processor 202 of first device 1002 may determine whetherthe received identity information is valid (based on step 1234 and/oroptional step 1236). When processor 202 determines that the receivedidentity information is not valid, step 1238 may proceed to step 1240.At step 1240, processor 202 may deny access to security credentials 224stored in secure internal storage 204. Step 1240 may proceed to step1228 such that system 1000 returns to the connected (but not identified)state.

When processor 202 determines that the received identified informationis valid, step 1238 may proceed to step 1244. At step 1244, processor202 may form the identified state. In general, the received identityinformation may be used to verify the user identity and that the user isauthorized to use system 1000 for secure access to RALS 1008 using acombination of first and second devices 1002, 1004.

At step 1246, processor 202 of first device 1002 may permit access tosecurity credentials 224 in secure internal storage 204 (and/or 304),when system 1000 is in the identified state. At step 1246, system 1000may continue in the identified state as long as the predefinedconnection state between first and second device 1002, 1004 ismaintained and, optionally, the secured state is maintained.

First and second devices 1002, 1004 may also form an identified statefor a proximity dependent method, as described above with respect toFIG. 6C.

Referring next to FIG. 13, a flow chart diagram of an example method ofoperating system 1000 for authorized access to a restricted accesslocation is shown. At step 1300, first device 1002 may detect thataccess to a restricted access location is being requested. In someexamples, the requested access may be requested directly by first device1002. In some examples, the requested access may be by a furtherelectronic device coupled to first electronic device 1002. For example,processor 202 may determine that a user is attempting to access aparticular website or application that requires input of securitycredentials 224. At step 1302, processor 202 of first device 1002 maydetermine whether RAL information 226 related to the particularrestricted access location is stored in secure internal storage 204(and/or 304).

When it is determined, by processor 202, that RAL information 226 forthe particular restricted access location is not stored in securestorage 204, step 1302 may proceed to step 1304. At step 1304, a usermay enter the security credentials manually, such as via a user inputdevice.

When processor 202 determines, at step 1302, that the associated RALinformation 226 is stored in secure storage 204, step 1302 may proceedto step 1306. At step 1306, processor 202 may confirm whether first andsecond devices 1002, 1004 are in the identified state. When it isdetermined that first and second devices 1002, 1004 are not in theidentified state, step 1306 may proceed to step 1304.

When it is determined, at step 1306, that first and second devices 1002,1004 are in the identified state, step 1306 may proceed to step 1308. Atstep 1308, processor 202 may permit access to security credentials 224and may obtain security credentials 224 from secure internal storage 204(and/or 304). At step 1310, processor 202 may apply the obtainedsecurity credentials to gain access to the particular restricted accesslocation.

As discussed above, RAL(S) 1008 may include physical or virtuallocations. FIG. 13 may also be applied to a physical location, such as aphysical access point (e.g., door). Thus, at step 1310, application ofthe obtained security credentials (while in an identified state) maycause a locking mechanism at the physical access point to disengage,thereby permitting access to the physical access point.

For example, during registration (see FIGS. 11A and 11B) for a physicalaccess point (e.g., building door access), a user may verify theiridentity. Responsive to the verified identity, first electronic device1002 and/or second electronic device 1004 may receive and store a uniquekey associated with the physical access point.

For example, a user may physically present user identity informationuser to a building management office. Upon identity check verification(e.g., via server 1010), a physical access control server (which may beserver 1010 or a server associated with the physical access point incommunication with server 1010), the physical access server may assign aunique key to the user and send the unique key to a physical accesscontrol read/write device (not shown). The user may position firstand/or second electronic device 1002, 1004 within a predeterminedproximity of the read/write device, and the read/write device maytransfer the unique key to the first and/or second electronic device1002, 1004, for example using a NFC protocol. The same key or a derivedkey may be stored on the physical access control server.

As another example, a user may submit user identity information (e.g.,an employee ID or corporate email address), via network 1006 to server1010. Responsive to identity verification by server 1010 and dependingon the configuration of the physical access control system, the uniquekey may be generated by server 1010 or another server coupled to server1010 (or may be generated by first or second electronic device 1002,1004). The unique key may be stored on first and/or second electronicdevice 1002, 1004. The same unique key or a derived key may be stored ona physical access control server (not shown) associated with thephysical access point).

Once the user has registered for the physical access point, access tothe physical access point (e.g., the building door) may be obtained whenthe first and second electronic devices 1002, 1004 are in the identifiedstate (see FIGS. 12A and 12B). For example, the user may position firstand/or second electronic device 1002, 1004 within a predeterminedproximity to a physical access control reader (associated with thephysical access point). The reader requests authentication informationfrom first and/or second electronic device 1002, 1004. While first andsecond electronic devices 1002, 1004 are in the identified state, accessto the authentication information (i.e., security credentials) that isgenerated using the stored key is provided to the reader device. Theauthentication information is then verified, by communication of thereader with the physical access control server, to determine if accessis permitted or is denied. When access is permitted, reader will permitentry to the physical access point (e.g., unlock a door). Each time theunique key is used to attempt access, the physical access server maysend an indication to monitoring server 1014, and monitoring server 1014may record the event and any associated information.

Referring next to FIG. 14, a flow chart diagram is shown of an examplemethod of operating system 100 and/or 1000 to recover securitycredentials from first electronic device 102 (1002). In the descriptionbelow, reference is made to system 1000 (FIG. 10) using first device1002 and second device 1004. It is understood that the method shown inFIG. 14 may also be used with system 100 shown in FIG. 1.

At step 1400, a request to recover security credentials is received byserver 1010 from first device 1002. At step 1402, server 1010 mayconfirm with first device 1002 that first and second devices 1002, 1004are in the connected state.

When server 1010 determines that the first and second devices 1002, 1004are not in the connected state, step 1402 proceeds to step 1404. At step1404, first and second devices 1002, 1004 may be requested to form aconnected state, by repeating steps 1200-1228 (FIG. 12A). When first andsecond devices 1002, 1004 form a connected state, step 1404 may proceedto step 1406.

When server 1010 determines, at step 1402, that first and second devices1002, 1004 are in the connected state, step 1402 proceeds to step 1406.At step 1406, first device 1002 may send first and second unique deviceIDs 1016, 1018 to server 1010. At step 1408, steps 1116-1120 arerepeated (see FIG. 11A).

At step 1410, server 1010 may determine whether the received useridentity information is verified. When server 1010 determines that theidentity information is not verified, step 1410 may proceed to step1412. At step 1412, server 1010 may deny the recovery request. Atoptional step 1414, server 1010 may request that first device 1002perform a video based identity confirmation. At optional step 1416,server 1010 may blacklist devices and identity information.

When server 1010 determines that the received identity information isverified, step 1410 proceeds to step 1418. At step 1418, server 1010 maytransmit the global ID to first and/or second device(s) 1002, 1004.Server 1010 may encrypt the global ID that is sent to first and/orsecond device(s) 1002, 1004. At step 1420, first device 1002 (and/orsecond device 1004) may request user input of a personal user ID(previously generated by system 1000 during the registration process),and may receive the personal user ID via a user interface.

At step 1422, first device 1002 may determine whether the receivedpersonal user ID is verified (i.e., matches the previously generatedpersonal user ID stored in secure internal storage 204 on first device1002). When first device 1002 determines that the received personal userID is not verified, step 1422 may proceed to step 1412.

When first device 1002 determines that the received personal user ID isverified, step 1422 may proceed to step 1424. At step 1424, the globalID may be recovered on first and/or second devices 1002, 1004 (based onstep 1418). In some examples, the global ID may be recovered viadecryption using the personal user ID. At step 1426, first device 1002may create and present a new personal user ID to the user, for example,via a user interface. In some examples, the new personal user ID may bepresented on a user interface of second device 1004. The user may viewthe new personal ID and manually store the new personal user ID forrecovery, as discussed above. At step 1428, first and second devices1002, 1004, are now in the identified state and access to securitycredentials 224 may be permitted. In some examples, database(s) forsecurity credentials 224 and RAL(s) information 226 may be restored,based on user input of the previous personal user ID. For example, theprevious personal user ID may be used to decrypt a backed up securitycredentials database.

While the present disclosure has been discussed in terms of certainembodiments, it should be appreciated that the present disclosure is notso limited. The embodiments are explained herein by way of example, andthere are numerous modifications, variations and other embodiments thatmay be employed that would still be within the scope of the presentinvention.

1. A security system comprising: a first electronic device including anon-transitory memory storing computer-readable instructions and aprocessor; a second electronic device associated with a unique deviceidentifier, each of the first electronic device and the secondelectronic device including a wireless communication interface forwireless communication therebetween; and a secure storage on at leastone of the first electronic device and the second electronic device, thesecure storage configured to store one or more security credentialsassociated with a user for authorized access to one or more restrictedaccess locations; wherein execution of the computer-readableinstructions by the processor of the first electronic device causes theprocessor to: detect a presence of the second electronic device within apredetermined proximity range of the first electronic device, based onan indication received from the second electronic device via therespective wireless communication interface, establish a communicationchannel between the first electronic device and the second electronicdevice via each wireless communication interface, responsive to thedetected presence of the second electronic device, receive the uniquedevice identifier from the second electronic device via thecommunication channel, determine whether the received unique deviceidentifier matches a predetermined identifier stored in the securestorage, to validate the second electronic device, determine whether thefirst electronic device and the second electronic device maintain apredefined connection state, and permit access to the one or moresecurity credentials stored on the secure storage when the secondelectronic device is validated and the predefined connection state ismaintained.
 2. The system of claim 1, wherein the processor is furtherconfigured to establish the communication channel based on apredetermined wireless communication protocol.
 3. The system of claim 1,wherein the communication channel includes a secure communicationchannel.
 4. The system of claim 1, wherein the second electronic deviceincludes a wearable device.
 5. The system of claim 4, wherein the secondelectronic device includes a mechanism to detect coupling of the secondelectronic device to the user.
 6. The system of claim 5, wherein thesecond electronic device transmits a secured indication to the firstelectronic device when the mechanism detects the coupling to the user,the first electronic device permitting access to the one or moresecurity credentials when the second electronic device is validated, thepredefined connection state is maintained and the secured indication isreceived.
 7. The system of claim 1, wherein the processor is furtherconfigured to: receive authentication information from the user via auser interface; determine whether the authentication information for theuser is valid, the authentication information indicating whether theuser is authorized to use the first electronic device and the secondelectronic device; and permit access to the one or more securitycredentials when the second electronic device is validated, thepredefined connection state is maintained and the authenticationinformation is valid.
 8. The system of claim 7, wherein the systemfurther includes a registration server coupled to the first electronicdevice via a communication network, the registration server configuredto authorize the user for the first electronic device and the secondelectronic device.
 9. The system of claim 8, wherein the registrationserver is configured to permit recovery of access to the one or moresecurity credentials when the registration server verifies theauthentication information.
 10. The system of claim 1, wherein thesystem further includes a monitoring server coupled to at least one ofthe first electronic device or the second electronic device via acommunication network, wherein at least one of the first electronicdevice or the second electronic device is configured to detect initiatedaccess to one among the one or more restricted access locations andtransmit a message to the monitoring server, the monitoring serverstoring device usage information in the message.
 11. The system of claim10, wherein the at least one of the first electronic device or thesecond electronic device subsequently periodically transmits a messageto the monitoring server including current device usage information. 12.The system of claim 10, wherein the system is configured to perform acontinuous multi-factor authentication of the user via the firstelectronic device, the second electronic device and the monitoringserver.
 13. The system of claim 1, wherein at least one of firstelectronic device or the second device includes a computer, a mobilephone, a tablet, a smart watch, a health tracker, a fitness tracker, amultimedia device, a home automation system, an automated teller machineor a payment reader.
 14. The system of claim 1, wherein the one or morerestricted access locations include at least one of a virtual locationor a physical location.
 15. The system of claim 14, wherein one locationamong the one or more restricted access locations is configured toaccess the one or more security credentials, to permit or deny access tothe one location.
 16. A method for authorized access to one or morerestricted access locations, the method comprising: storing, on a securestorage of at least one of a first electronic device and a secondelectronic device, one or more security credentials associated with auser for authorized access to the one or more restricted accesslocations; storing, on the second electronic device, a unique deviceidentifier associated with the second electronic device, wherein each ofthe first electronic device and the second electronic device includes awireless communication interface for wireless communicationtherebetween; detecting, by the first electronic device, a presence ofthe second electronic device within a predetermined proximity range ofthe first electronic device, based on an indication received from thesecond electronic device via the respective wireless communicationinterface; establishing, by the first electronic device, a communicationchannel between the first electronic device and the second electronicdevice via each wireless communication interface, responsive to thedetected presence of the second electronic device; receiving, by thefirst electronic device, the unique device identifier from the secondelectronic device via the communication channel; determining, by thefirst electronic device, whether the received unique device identifiermatches a predetermined identifier stored in the secure storage, tovalidate the second electronic device; determining, by the firstelectronic device, whether the first electronic device and the secondelectronic device maintain a predefined connection state; andpermitting, by the first electronic device, access to the one or moresecurity credentials stored on the secure storage when the secondelectronic device is validated and the predefined connection state ismaintained.
 17. The method of claim 16, wherein the second electronicdevice includes a wearable device, the method further comprising:detecting, by the second electronic device, coupling of the secondelectronic device to the user; transmitting, by the second device, asecured indication to the first electronic device when the coupling tothe user is detected; and, permitting, by the first electronic device,access to the one or more security credentials when the secondelectronic device is validated, the predefined connection state ismaintained and the secured indication is received.
 18. The method ofclaim 16, the method further comprising: receiving, by the firstelectronic device, authentication information from the user via a userinterface; determining, by the first electronic device, whether theauthentication information for the user is valid, the authenticationinformation indicating whether the user is authorized to use the firstelectronic device and the second electronic device; and permitting, bythe first electronic device, access to the one or more securitycredentials when the second electronic device is validated, thepredefined connection state is maintained and the authenticationinformation is valid.
 19. The method of claim 18, the method furthercomprising: receiving, by a registration server, a request for recoveryof access to the one or more security credentials from at least one ofthe first electronic device or the second electronic device; andpermitting, by the registration server, recovery of access to the one ormore security credentials when the registration server verifies theauthentication information.
 20. The method of claim 16, the methodfurther comprising: detecting, by at least one of the first electronicdevice or the second electronic device, initial access to one among theone or more restricted access locations; and transmitting, by at leastone of the first electronic device or the second electronic device, amessage to a monitoring server; and storing, by the monitoring server,device usage information included in the received message.